Blockchain-based method and system for specifying the recipient of an electronic communication

ABSTRACT

A method and corresponding system is presented for controlling a blockchain transaction output and/or specifying the recipient of the output. It also provides a method of controlling and/or generating an electronic communication. The unlocking script is provided in order to spend an output from a further transaction (Tx 2 ) on the blockchain. The input of the transaction (Tx 1 ) and/or the output of the further transaction (Tx 2 ) may be associated with a tokenised asset represented on, or referenced via, the blockchain. The notification address may be associated with an asset or resource represented on the blockchain, or a controller of an asset or resource represented on the blockchain. The notification address may be a network address, a cryptographic key, a uniform resource locator (URI), email address or any other address or identifier which can be represented in the metadata of a transaction script and used as a destination for an electronic communication.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/344,295, filed Apr. 23, 2019, entitled “BLOCKCHAIN-BASED METHOD ANDSYSTEM FOR SPECIFYING THE RECIPIENT OF AN ELECTRONIC COMMUNICATION,”which is a 371 National Stage of International Patent Application No.PCT/IB2017/056584, filed Oct. 24, 2017, which claims priority to UnitedKingdom Patent Application No. 1617951.7, filed Oct. 25, 2016, andUnited Kingdom Patent Application No. 1617950.9, filed Oct. 25, 2016,the disclosures of which are incorporated herein by reference in theirentirety.

SUMMARY

This invention relates generally to distributed ledger and blockchaintechnology, and more particularly to the use of blockchain technologyfor implementing systems for the automated control of computer-executedprocesses. An embodiment of the invention provides a solution forrecording and controlling the ownership or control of an electronicasset via the blockchain, and for generating and effecting blockchaintransactions in response to the current ownership data. The inventionalso provides a novel and advantageous solution for controlling andenabling the transmission of an electronic communication to a recipient.It utilises blockchain technology to facilitate the storage of arecipient address or identifier so that privacy and/or security can beenhanced, and enables the recipient to specify and/or alter thenotification address stored on the blockchain. The invention is suitedfor, but not limited to, use with the Bitcoin blockchain.

In this document we use the term ‘blockchain’ to include all forms ofelectronic, computer-based distributed ledgers, including, but notlimited to blockchain and transaction-chain technologies, permissionedand un-permissioned ledgers, shared ledgers and variations thereof. Themost widely known application of blockchain technology is the Bitcoinledger, although other blockchain implementations have been proposed anddeveloped. While Bitcoin may be referred to herein for the purpose ofconvenience and illustration, it should be noted that the invention isnot limited to use with the Bitcoin blockchain and alternativeblockchain implementations and protocols fall within the scope of thepresent invention.

A blockchain is a consensus-based electronic ledger which is implementedas a computer-based decentralised, distributed system made up of blockswhich in turn are made up of transactions. Each transaction includes atleast one input and at least one output. Each block contains a hash ofthe previous block to that blocks become chained together to create apermanent, unalterable record of all transactions which have beenwritten to the blockchain since its inception.

Transactions contain small programs known as scripts embedded into theirinputs and outputs, which specify how and by whom the outputs of thetransactions can be accessed. On the Bitcoin platform, these scripts arewritten using a stack-based scripting language.

In order for a transaction to be written to the blockchain, it must be“validated”. Network nodes (miners) perform work to ensure that eachtransaction is valid, with invalid transactions rejected from thenetwork. Software clients installed on the nodes perform this validationwork on an unspent transaction (UTXO) by executing its locking andunlocking scripts. If execution of the locking and unlocking scriptsevaluate to TRUE, the transaction is valid and the transaction iswritten to the blockchain. Thus, in order for a transaction to bewritten to the blockchain, it must be i) validated by the first nodethat receives the transaction—if the transaction is validated, the noderelays it to the other nodes in the network; and ii) added to a newblock built by a miner; and iii) mined, i.e. added to the public ledgerof past transactions.

Although blockchain technology is most widely known for the use ofcryptocurrency implementation, digital entrepreneurs have begunexploring the use of both the cryptographic security system Bitcoin isbased on and the data that can be stored on the Blockchain to implementnew systems. It would be highly advantageous if the blockchain could beused for automated tasks and processes which are not limited to therealm of cryptocurrency. Such solutions would be able to harness thebenefits of the blockchain (e.g. a permanent, tamper proof records ofevents, distributed processing etc) while being more versatile in theirapplications.

One area of current research is the use of the blockchain for theimplementation of “smart contracts.” These are computer programsdesigned to automate the execution of the terms of a machine-readablecontract or agreement. Unlike a traditional contract which would bewritten in natural language, a smart contract is a machine executableprogram which comprises rules that can process inputs in order toproduce results, which can then cause actions to be performed dependentupon those results.

Another area of blockchain-related interest is the use of ‘tokens’ (or‘coloured coins’) to represent and transfer real-world entities via theblockchain. A potentially sensitive or secret item can be represented bythe token which has no discernable meaning or value. The token thusserves as an identifier that allows the real-world item to be referencedfrom the blockchain.

Data relating to smart contracts needs to be registered, tracked andrecorded. For example, it is necessary to record data relating to theowner(s) of an asset managed by a smart contract. This is particularlyimportant in relation to smart contracts relating to assets which areowned by a number of entities, where the ownership is split into shares.In such cases, a transfer of ownership needs to be recorded in a securemanner. It is also important that relevant costs can be accrued againstthe asset and/or income generated and paid from it. Another importantconsideration is that it is often desirable to protect the identity ofthe real world parties involved.

In general, holding a tokenised asset against a blockchain means thatthere is a UTXO (unspent transaction output) that is allocated to thecurrent asset holder and which determines the scale of that assetholder's current holding. This is encapsulated within the redeem scriptrequired to transfer the asset, and would generally be of the form:

X OP_CHECKMULTISIG (Metadata-A Metadata-B PublicK-A) Y

However, the information that is held within the blockchain is not thisscript, but rather a hash of the script. This means that the criticalpublic key information is not available for public inspection.

In some cases, the income distribution is paid via the same tokenisedcommodity as the original asset e.g. when additional shares in a companyare issued as the dividend. In such cases, the non-availability of thepublic key is not a problem as the income distribution can simply bepaid to the same redeem script hash as the original issuancetransaction.

However, in the more common scenario where the income distribution ispaid as an alternative asset (for example BTC dividend against a share),then this lack of public key information means that, in accordance withthe current state of the art, a separate, off-chain, database has to bemaintained of the public keys associated with each issuance transaction.Whilst such a solution is clearly viable, it means that there are twosystems (the blockchain and the off-chain database) which aremaintaining the asset register. This injects complexity into thesolution and the possibility that the two databases will become out ofstep with one another. It also requires an efficient storagearrangement.

Thus, it is desirable to provide a solution which, at least:

eliminates the requirement for this second database, and thus the riskand inefficient storage requirements that it entails, by enabling theautomated determination of where the income should be paid to

is able to pay that income in such a manner that ensures that only thecurrent asset holder is in a position to claim those funds

provides a generic mechanism to generate actions and technical responses(e.g. in response to income generation) in proportion to the currentownership of an asset represented and/or referenced via a blockchain

uses blockchain transactions to allow the secure, automated transfer ofan asset and record those transfers and payments on the blockchain, thusproviding benefits such as a tamper-proof record of events and data

enables the protection of identities of ‘real world’ parties such asasset owners; the solution should enable or facilitate anonymity

provides a solution for enabling and controlling electroniccommunications which need to be sent to “unknown” parties.

Such an improved solution has now been devised. The present inventionprovides at least these technical effects discussed above. The inventionis defined in the appended claims.

Therefore, in accordance with the invention there may be provided acontrol method and corresponding system. The method may control thetransmission of an electronic communication. It may be a method ofestablishing an electronic communication channel between two or moreparties.

Additionally or alternatively, the invention may be arranged tofacilitate and/or enable the completion of an incomplete blockchaintransaction. Thus, the invention may be described as a method to controlor influence the validity and/or propagation of a blockchain transactionon a blockchain network.

Herein, the terms “communication,” “notification,” and “alert” may beused interchangeably.

The invention may provide a method of controlling and/or generating anelectronic communication. Additionally or alternatively, the inventionmay provide a solution for determining the destination of an electroniccommunication/transmission. It may be a blockchain-implemented solution.The invention may be a method/system arranged to enable (electronic,off-blockchain) communication with an anonymous recipient, orpseudo-anonymous recipient. This recipient may be an asset owner orcontroller, for example, although the invention is not limited in thisregard. The communication may be sent using information stored, or“embedded,” within a sequence of blockchain transactions. The inventionmay be described as a method of specifying and/or determining thedestination of an elecontric communication via a blockchain.

The method may comprise the step: sending a signal to an address. Theaddress may be a notification address. The signal may be called or serveas an (electronic) notification or communication.

The invention is not limited with regard to the context, purpose orcontent of the notification.

The notification may be provided as metadata within an unlocking scriptassociated with an input of a transaction (Tx₁) on a blockchain. Theterm “identifier” may be used interchangeably with “address.” Thistransmission step may triggered by an event. The event may be specified,determined or influenced by a smart contract. Transmission (sending) ofthe notification may be performed by a computer-based resource. It maybe performed as at least part of an automated process.

The notification may serve as a request and/or trigger for completion ofthe incomplete transaction. The method may comprise the step ofcompleting the incomplete transaction. Completion may comprise theprovision of a cryptographic signature.

The unlocking script may be provided in order to spend an output from afurther transaction (Tx₂) on the blockchain. (This may be a “preceding”transaction on the blockchain in the sense that an input of transactionTx₁ may spend an output of transaction Tx₂).

Thus, the invention may comprise the step of requiring the provision ofa notification address in an unlocking script in order to unlock alocking script. This step may be repeated. Thus, a sequence ofnotification addresses may be required and supplied. A notificationaddress may be required in order to spend each output in a chain ofblockchain transactions. This allows the provision of a differentaddresses over time. Thus, the invention enables and facilitateschanging of the recipient address for the notification.

The input of the transaction (Tx₁) and/or the output of the furthertransaction (Tx₂) may be associated with a tokenised asset representedon, or referenced via, the blockchain. This token may be referred to asa “coloured coin.”

The electronic notification may comprise:

an incomplete or complete blockchain transaction, and/or

information relating to an incomplete or complete blockchaintransaction.

It may be incomplete in the sense that it is missing a piece of requireddata.

It may comprise information relating to the location of thecomplete/incomplete transaction, or how to access it.

The notification address may be associated with an asset or resourcerepresented on the blockchain, or a controller of an asset or resourcerepresented on the blockchain. The controller may be the same or adifferent entity from the actual (“real world”) owner of the asset.

The method may further comprise the step of:

traversing the blockchain to identify the transaction (Tx₁) or furthertransaction (Tx₂). The skilled person would understand how thistraversal would be performed as per known techniques.

The method may comprise the step of:

submitting a transaction to a blockchain, wherein the transaction (Tx₁)comprises an unspent output (UTXO) which includes a redeem script thatrequires the provision of a notification address within the metadata ofan unlocking script in order to spend the output (UTXO).

The unspent output (UTXO) may transfer ownership of, or otherwise relateto, a tokenised asset represented on, or referenced via, the blockchain.

The notification address may be provided as a parameter in the unlockingscript of the transaction (Tx₁). It may be provided as a secondparameter.

The method may comprise the step of using a redeem script to ensure thata notification address has been provided in the unlocking script. Theredeem script may comprise a value indicating how many notificationaddresses must be supplied by the unlocking script.

A plurality of notification addresses may be provided within theunlocking script.

The notification address may be a network address, a cryptographic key,a uniform resource locator (URI), email address or any other address oridentifier which can be represented in the metadata of a script and usedas a destination for an electronic communication. Thus, the notificationaddress may serve as an identifier for the recipient of thenotification/communication.

At least one step of the method may be performed by an automatedcomputing resource or agent.

This may be called a “bot” or “oracle.”

The method and/or system may be substantially as described below in thesection entitled “Notification Address Embedded Within the Blockchain.”

The invention may also provide a computer-implemented system arrangedand configured to perform the steps of any embodiment of the methoddescribed herein.

The system may comprise:

a blockchain;

at least one autonomous computing agent arranged and configured to:

traverse the blockchain; and/or

generate and or send the electronic notification.

Any feature described in relation to the method may also be applicableto the system and vice versa.

The invention may be substantially as described in the illustrativeembodiment described in the following examples, description and figures.These and other aspects of the present invention will be apparent fromand elucidated with reference to, the embodiment described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

An embodiment of the present invention will now be described, by way ofexample only, and with reference to the accompany drawings, in which:

FIG. 1 provides an overview of an illustrative embodiment of theinvention.

FIG. 2 provides an illustration of the traversal logic which is employedwhen iterating over the blockchain to determine the current ownership ofthe asset(s).

FIG. 3 provides an illustration of the transaction output which isrequired in accordance with an embodiment of the invention.

FIG. 4 provides an illustration of the construction of the initial,incomplete blockchain transaction.

FIG. 5 provides an illustration of the incomplete transaction of FIG. 4after it has been amended and completed by the asset controller.

FIG. 6 provides an illustration of an embodiment of the invention, inwhich a notification is sent to the asset controller to inform them thatthere is an incomplete transaction which needs their attention andmodification.

FIG. 7 shows an illustration of a use case model in accordance with anembodiment of the invention.

FIG. 8 provides blockchain transaction number 100.10 which, in relationto the example provided below, could be used to generate shares in theasset represented on the blockchain.

FIG. 9 provides blockchain transaction number 100.120 which, in relationto the example provided below, could be used to issue shares of theasset to a recipient. Note that the notification address is specified asa requirement in the ScriptSig. This forces the recipient (i.e., theasset owner or controller) to provide a notification address as metadatain an unlocking script when “claiming” the shares via an input in asubsequent transaction.

FIG. 10 provides blockchain transaction number 150.10 which could beused to transfer ownership of part of the asset to a recipient. In thiscase, the current asset controller retains part of the asset and assignsor transfers the other portion to one or more other parties.

FIG. 11 provides incomplete blockchain transaction number 400.1 whichcould be generated in relation to the example provided below.

FIG. 12 provides blockchain transaction number 400.10 which is thecompleted version of the incomplete transaction shown in FIG. 11 , asmodified by the asset controller.

DETAILED DESCRIPTION

The present invention provides a generic solution that allows thecontrol of secure transfers of digital entities via inputs and outputsof blockchain transactions. In the examples provided herein, theinvention is discussed for illustrative purposes in the context ofpaying income or accrued costs against a blockchain-registered assetaccording to the terms of an underlying investment contract e.g. indirect proportion to how the ownership of that asset has been split. Forexample, if an asset has been split into 100 shares, then the income tobe paid would be calculated per share.

However, it is important to note that the invention is not limited tosuch use case scenarios and provides a more generic transfer-controlsolution and notification solution which can be utilised to advantage ina variety of applications and contexts.

Key Terms

This technical specification uses the following terms throughout todefine key concepts and components.

Name Type Asset The asset is an actor that represents something that canapportion ownership to one of more Asset holders in variable amounts.The Asset is both a private key plus an agent as defined below. Theseamounts can be simple percentages (e.g. 5%) or units (e.g. 100 units).Agent/oracle The ‘agent’ is a software-implemented resource whichperforms automated actions on behalf of the asset. The agent may bereferred to as an “oracle” or a “bot.” Essentially, the agent is asoftware component which is programmed to implement the terms of thesmart contract, respond appropriately to pre-defined triggers, evaluateconditions using inputs from sources which may be off-chain etc. As suchagents are known in the art and readily understood by the skilledperson, and are not the focus of the present invention, theirimplementation are not described in detail herein. Asset Holder Theasset holder is an actor that represents something that currently holdsa proportion of an Asset. The holder may be referred to as a“controller” or “owner” Secondary The secondary asset holder is an actorthat represents something that holds Asset Holder a proportion of anAsset which is gained from a transaction other than the originalissuance transaction (e.g. the on-sell of the asset). Repository Therepository is an actor that represents the entity responsible for thestorage (and potentially on-going maintenance) of the Contract documentdefining the payment schedule associated with the asset. Contract TheContract is the document that contains the formal definition for how todetermine the payments, and the schedule associated with the paymentsfor this asset. This is a smart contract, as is known in the art. It mayalso (depending on the implementation method used) hold detailed of thecurrent ownership of the asset.

As shown herein, the invention provides an automated, secure and robustmechanism which allows at least the following:

the ability to determine the current ownership of an asset from ablockchain (such as, for example, the Bitcoin blockchain);

the ability to control transmission of electronic communications tounknown parties relevant to the asset; and

the ability to pay income generated by the asset in proportion to thecurrent ownership of the asset.

In the latter two cases, this process can used to advantage where theasset maintains a separate database of ownership, or where the ownershipis hidden by the blockchain via the use of (payment) addresses.

The invention provides at least two advantageous aspects:

1. The ability to make payments via a blockchain to owners of an assetwhere the owner remains unknown and anonymous to the asset.

2. The ability to notify anonymous owners using information storedwithin a sequence of blockchain transactions. This aspect is the focusof the present application.

Determining Current Ownership of an Asset Represented on a Blockchain

In order to apportion costs/income against an asset represented on theblockchain, it is essential to be able to determine the currentownership of that asset. There are two mechanisms one could use toachieve this:

-   -   The ownership can be maintained in a separate register off-chain        maintained by the asset (and updated by forcing transfers to be        counter-signed by the asset). This mechanism is ideal for        regulated assets where formal “Know Your Customer” rules apply.    -   The ownership can be determined by scanning the transactions on        the blockchain to dynamically generate the current ownership        list. It should be noted that this approach does not determine        the ownership per se but rather it identifies the Bitcoin        addresses that are responsible for the asset. This may be        referred to as the “asset controller,” which may or may not be        the actual owner. This blockchain-traversal technique is used by        the present invention.

Generating Ownership-Related Actions: E.g. Calculating and Paying Income

In order to pay income from the asset in proportion to the currentownership of the asset:

the asset must have the ability to determine the current ownership;

the asset must be able to record the total income for a given period;

the asset must be capable of dividing the income between the currentownership;

the asset must be capable of netting costs from the income;

the asset must be capable of holding income where previous costs havenot been paid; and

the asset must be capable of triggering the payment of the income suchto the current asset holders.

This income can be rolled up at the end of a time-period (e.g. every sixmonths) or as it is generated (e.g. immediately). Depending on thenature of the contract, the same conditions would allow for pro-ratapayment of income with some contracts only allowing payment for a periodto the current holder.

Technical Solution

The technical solution provided by the invention provides a mechanism bywhich the controller of an investment or asset, via an agent and a smartcontract, can generate a set of payment transactions to both re-coup itscosts or pay income. The solution relies on an automated oracle process(or multiple oracle processes depending on the structure of theunderlying contract) being triggered by an off-chain condition. Forexample, this condition might be a date on which to pay returns. Oncethis trigger condition trips the oracle will:

calculate the total payment amount for the asset as a whole;

calculate the individual payments across the current ownership split forthe asset based-on the payment rules (for example, pro-rata); and

create payment transactions for each of the individual asset holders.

FIG. 1 shows the basic flow of how the technical solution determines theindividual payments to make.

The steps in the flowchart of FIG. 1 are defined in more detail in thesubsequent sections:

Step Details 1 Find ‘anchor’ transaction This specifies to the oraclethe point to start the traversal of the transaction history to determinethe current ownership of the assets. The anchor may also be referred toas the “issuance transaction” See section ‘Traversing from the issuancetransaction’ for more information. 2 Traverse transaction history todetermine current UTXO set This looks for all the “spends” of theassets, starting from the point of issuance, to determine the currentunspent output UTXO (which determines the current location/ownership ofthe assets). See section ‘Traversing from the issuance transaction’ formore information. 3 For each UTXO, create distribution transaction Thisstep simply ensures that steps 3 through 6 are repeated for each UTXOdiscovered in step 2 above. A ‘raw’ distribution transaction is createdand broadcast in an incomplete state (it is missing a key transactionsignature). The distribution transaction will ultimately be used totransfer funds to the specified recipient, once the distributiontransaction has been completed. See section ‘Creating the distributionpayment’ for more information. 4 Broadcast distribution transaction Thissteps broadcasts the incomplete transaction to interested parties. Sinceit is known that only the current controller/owner of the asset cancomplete the transaction and claim the funds (because of therequirements specified in the locking script of the output), this can bepublished through any open channel. However, it cannot be broadcastthrough the blockchain itself, for reasons explained below. 5 Assetowner re-directs distribution to their select key This step allows thecurrent asset controller/owner to re-direct the funds from the broadcasttransaction to their selected private key. See section ‘Re-directing thedistribution payments’ for more details. 6 Distribution transactionpublished to the blockchain This final step locks the completed andre-directed transaction to the blockchain in the normal manner.

Traversing the Blockchain from the Issuance Transaction

In order to determine the current location (ownership) of the shareswithin the asset, the relevant oracle needs to be able to traverse theblockchain, starting from the original issuance transaction to determinewhere the shares of the current asset currently reside. The issuancetransaction is referred to as the “anchor transaction” in FIG. 1 . FIG.2 shows a sample chain of transactions which might be used during such atraversal. Essentially, this process involves moving from transaction totransaction on the blockchain, following a trail, until the oracle findsa UTXO relating to the asset. As this output has not been spent, itindicates that the asset controller that spent the last input on theasset must still be the controller. Therefore, the traversal process canhalt at this transaction.

Each individual Issue or Transfer transaction output has an associatedRedeem Script. From the fact that the transaction output is unspent, theoracle can determine which Redeem Script was used to spend the outputfrom the previous transaction and therefore ‘owns’ which proportion ofthe asset at any point in time.

Creating the Distribution Payments

By knowing the redeem script, the income distribution transaction canmake use of the SIGHASH_NONE capability to allow the output to beredirected, but only in a manner that the controller of the RedeemScript can change. To do this, the distribution transaction needs to beconstructed as illustrated in FIG. 3 .

The distribution transaction will have two outputs:

1. an output which transfers (re-issues) back to the current controllerso that next time the traversal process is performed, the samecontroller is determined to be the current one; and

2. an output which transfers some electronic funds to the controller.

The re-issuance output can be constructed since it can simply replay(i.e. copy) the Redeem Script hash from the previous issuance/transfertransaction.

However, it is impossible to construct the distribution transaction inone step based on the number of signatures that are required andbecause, at the point of construction, the locking script for the IncomePayment to A cannot be constructed.

To solve this, the distribution transaction is originally constructedand broadcast in the format shown in FIG. 4 .

By setting the signature hash on the inputs to SIGHASH_NONE, then eitherone of the outputs can be changed. However, by locking in the lastissuance transaction, only the legitimate owner of the asset can makethe change since they are required to sign the input (and wouldobviously not do so unless it was in their interests). It should benoted that there is no necessity for any signature to be supplied on theLast Asset Issue/Transfer to A Transaction. It is shown in FIG. 4 on theassumption that the asset issuer is a counter-signatory for any transfertransaction; if they are not then this transaction is simply bound usingthe signature on the Income for Distribution which achieves the sameeffect.

Re-Directing the Distribution Payments

When the current Asset owner picks up the incomplete, templatetransaction, they determine that it is in their best interests tocomplete the transaction which they do by signing the Last AssetIssue/Transfer to A Transaction input after changing the income paymenttransaction to pay this income to themselves. This amended, completetransaction is illustrated in FIG. 5 . As the transaction is nowcomplete it can be mined.

Thus, the outcome has been achieved without there being any requirementfor the Asset to know anything about the underlying owner of the assetother than their ownership share that was contained within theblockchain record itself.

The Need For Notification

As described above, the payment distribution transaction is initiallycreated in an incomplete form. It then needs to be communicated somehowto the asset controller(s) so that they are aware of its existence andcan make the necessary modifications to complete it and submit it to theblockchain.

However, the incomplete transaction cannot be broadcast via theblockchain itself. This is because, by default, the blockchainpropagation nodes will not propagate incomplete transactions across thenetwork. As the original version of the distribution transaction isincomplete (it is missing a signature), it is unlikely that thecontroller/owner will be able to pick up the incomplete transaction andapply a signature prior to it being dropped by the network. Whilst thisdoes not impact the ownership of the asset, it does mean that therelevant parties do not get paid the income that they are owed.

To resolve this, there needs to be a channel that can be used tobroadcast the incomplete transaction to interested parties (or at leastmake them aware of its existence and/or location).

There are various possible methods to resolve this, including:

The contract could publish a ‘broadcast’ channel as part of the contractupon which all incomplete transactions will be broadcast with owners ofthe assets listening to that channel to determine transactions ofinterest and reacting to them. This publish/subscribe mechanism is astandard IT feature.

Upon sale or other transfer of the asset, the new asset owner/controllerlocks a notification address into the sale transaction. This enables acommunication channel to be set up without any other information beingknown about the asset owner/controller. The asset will then use thisprivate channel to send the incomplete transaction to the current owner,or notify them that the transaction is available from an accessiblelocation e.g. for download and subsequent completion.

Neither of these solutions impact or affect the first aspect of theinvention as described above, in that the asset is still unaware of theownership of itself other than from information held upon the blockchainitself. In the following example, the transactions make use of thesecond option for transaction notification. This notification techniqueforms a second, novel aspect of the invention and offers privacy oranonymity of the transaction information.

Notification Address Embedded within the Blockchain

This novel and advantageous aspect of the invention provides a solutionto the propagation problem identified above by enabling the ability toembed a notification address within the blockchain transaction. Thenotification address can then be used for subsequent notifications.

The notification can take any suitable form, such as for example anemail. In such cases, the email would be sent to the email address thathas been embedded in the previous transaction. However, other forms ofelectronic communications known in the art also fall within the scope ofthe invention. Essentially, the identifier which is captured in theinitial transaction serves as the address or location to whichnotifications will be sent.

This section explains how this model operates and is the focus of thepresent application.

It should be noted that this notification technique can be used toadvantage as a solution to a problem in its own right, and in respect ofa wide variety of contexts and applications, independently from thefirst aspect of the invention described above.

This solution means that a communication can be sent to a recipientwithout the need for any further information to be supplied or known.The invention therefore provides an enhanced alert, notification orcommunication technique which preserves or enhances privacy andsecurity. No additional information about the recipient is requiredother than the address that is provided in, and then extracted from, thetransaction script. This lends itself to being implemented by anautomated process such as a bot.

Transmission of the notification to the specified address may betriggered by an event. The event may be specified in, or influenced by,a smart contract.

The notification can simply be a signal sent to the address, and/or maycontain predetermined content. Thus, a desired, informative message canbe transmitted. Additionally or alternatively, receipt of thenotification may serve as a signal to an automated process and thustrigger a pre-determined or programmed response e.g. to supply asignature to the transaction, or perform some other action.

The invention is not limited with regard to the content of thenotification message that is dispatched to the embedded address. Thenotification may, in some cases, include a copy of the incompletetransaction. In the present example, though, the role of thenotification address is to ensure that the relevant interestedactors—which may be a human or computer-based resource—can be notifiedor alerted to the need to apply their signatures (and make otheramendments) to a given target transaction as the author of that targettransaction has no other information about them. In effect, then, theinvention enables the fulfilment, completion of a future blockchaintransaction. Upon provision of the necessary signature(s), the partial,invalid transaction is converted into a viable, valid transaction thatcan be accepted by the blockchain. Therefore, the invention solves theproblem of how to control, facilitate and/or enable the validity of ablockchain transaction and its propagation on a blockchain network.

In order to do this, a ‘seed’ transaction needs to be created thatforces the capture of notification address in all subsequenttransactions. This would usually be prior to an issuance transaction(for a standard tokenised transaction). This issuance or ‘source’transaction now requires additional attributes to be supplied on theunlocking script that contain the notification addresses. The full flowof this process is shown in FIG. 6 .

Notification Redeem Script

The key format for the unlocking script is as follows:

<count of notification addresses> <notification address #1><notification address #2> ... <notification address #n>

  <signature #1> . . . <signature #n?

As can be seen from the above structure, the elements shown in the boxrepresent a standard script input, but the prefix is novel. This prefixtakes the form shown here:

OP_DUP OP_IF  OP_1SUB  OP_SWAP  OP_DROP  OP_DUP OP_ENDIF OP_IF  OP_1SUB OP_SWAP  OP_DROP  OP_DUP OP_ENDIF OP_IF  OP_1SUB  OP_SWAP  OP_DROP OP_DUP OP_ENDIF OP_IF  OP_1SUB  OP_SWAP  OP_DROP OP_ENDIF OP_VERIFY<Script remainder e.g. signature verification>

This particular example means that the <Count of notification addresses>can range from 1 to 4, but the structure can be extended to support adifferent maximum if required. This script prefix effectively drops therelevant notification addresses from the stack, and then checks to makesure that the number of notification addresses matches the number thatshould have been there.

Use Case Model

The model provided in FIG. 7 shows the key use cases involved within thenon-debt lending model.

[100] Issuance of Shares

The Asset needs to issue shares in itself to the appropriate AssetHolder, ensuring that it captures the notification address for thatentity during the issuance. The primary actor in this is the Asset.

Main Success Scenario:

This step is required only where the current holder's notificationdetails are maintained on the blockchain itself.

Step Details 100.10 Shares Generated In this step, the Asset splitstheir stock of BTC into UTXO's of the correct amount for subsequentissuance to an individual Asset Holder (the stepperformed in 100.20below). The transaction is made to a pay to script hash addresscontrolled by the Asset but which allows the injection in step 100.20 ofthe new Asset Holder's notification address. 100.20 Shares Issued Inthis step, the Asset takes each individual fragment generated in step100.10 above and issues it to the appropriate Asset Holder locking thatholder's notification address into the issuance instruction within asecond parameter to the unlocking script.

The Share Generation transaction is shown in FIG. 8 as Transaction100.10

The full redeem script for Output 1 of transaction 100.10 is shownbelow.

  OP_DROP OP_CHECKSIG

The Share Issuance transaction is shown in FIG. 9 as Transaction 100.20

The full redeem script for Output 1 of transaction 100.20 is shownbelow.

OP_DUP OP_IF  OP_1SUB  OP_SWAP  OP_DROP  OP_DUP OP_ENDIF OP_IF  OP_1SUB OP_SWAP  OP_DROP  OP_DUP OP_ENDIF OP_IF  OP_1SUB  OP_SWAP  OP_DROP OP_DUP OP_ENDIF OP_IF  OP_1SUB  OP_SWAP  OP_DROP OP_ENDIF OP_VERIFYOP_CHECKMULTISIG OP_2 <PubK-AssetHolder> <PubK-Asset> OP_2

This example redeem script allows a subsequent on-sell to transferownership to up to four buyers. If the purchase relates to more thanfour buyers, then multiple transactions would be required. It should benoted that it is clearly possible to extend (or restrict) the potentialnumber of new purchasers by repeating (or reducing) the ‘if’ blockwithin the above script.

[150] On-Sell of Shares

The Asset Holder needs to on-sell a proportion of its holdings toanother interested party. The primary actor in this is the Asset Holder.

Main Success Scenario:

Step Details 150.10 Capture notification address for each purchaser Thecurrent asset holder captures the notification address for the newpurchaser through any mechanism that they choose. 150.20 Create re-selltransaction template The current asset holder constructs a re-selltransaction and captures the order of the transaction outputs. The orderof the created transaction outputs is used to structure the unlockingscript as follows: <Number of transaction outputs> Notification Addressfor TxOut-0> Notification Address for TxOut-1> //if requiredNotification Address for TxOut-2> //if required Notification Address forTxOut-3> //if required <Sig-AssetHolder> 150.30 Asset counter-signstemplate transaction The Asset provides the second signature to there-issuance transaction. 150.40 Transaction published & mined Thetransaction is then published to the blockchain and subsequently minedinto a block.

This creates a number of key features that are necessary to support theunderlying income distribution.

The sale can only be to a maximum of four new holders (e.g., a fouroutput transaction, but can be any number from 1 to 4).

If the sale includes the retention of some of the shares, then onlythree new holders can be supported since only of the slots is taken forthe re-allocation back to the current holder.

Transaction 150.10

In example transaction 150.10 provided in FIG. 10 , the transactionimplements a partial sell with the current asset holder retaining astake and selling one other stake to a new holder. It should be notedthat in a real-world scenario it is possible that an additional input tocover the mining fee may be required. This has been ignored in thetemplate of FIG. 10 , transaction 150.10 to improve readability.

The redeem script for output 1 of transaction 150.10 (FIG. 10 ) is thesame as that for transaction 100.20 (FIG. 9 ) with the exception thatthe public keys are:

<PubK-SecondaryAssetHolder> and <PubK-Asset>.

This redeem script for output 2 of transaction 150.10 (FIG. 10 ) iscompletely identical as that for transaction 100.20 (FIG. 9 ).

[200] Determination of Ownership

The Asset needs to determine how to allocate the income for payment tothe current asset holders even though it is unaware of their identity.The primary actor in this action is the Asset.

Main Success Scenario:

Step Details 200.10 Determine Current Asset Allocation In this step, theAsset traverses the pool of UTXOs from their original issuancetransaction generated by the asset. Where the original UXTO has beenspent (i.e. the asset has been transferred again), then the outputs fromthis new transaction is checked according to step 200.10. In performingthis traversal, the notification address from the ‘spent’ input isrecorded. Each original issuance UTXO is traversed until a set ofcurrent issuance blocks is determined, plus the notification address andredeem script for that output.

[300] Calculate Payment

Here, the Asset wishes to calculate the amount of income that should bepaid to its current owners. The primary actor for this action is theAsset.

Main Success Scenario:

Step Details 300.10 The Asset pulls in all the information for theperiod to calculate the income due. Note: this may be zero. Note: themechanism used will be specific to the nature of the asset itself andformally defined within the associated contract document. 300.20 Theoutputs from the preceding step is allocated on a per share basisaccording to the terms of the contract (for example by dividing theoutput value with the number of shares in existence). The rounding ruleswill tend to be defined within the associated contract document but willnormally be down for income due. 300.30 The per-unit apportionmentderived in step 300.20 is now allocated on a per- holding basis througha simple multiplication using the holding allocation derived in use case200. 300.40 Use case 400 is now performed for each individual holdingidentified out of step 300.30

[400] Paying the Income

Here, the Asset wishes to pay income to its owners in proportion totheir ownership. The primary actor is the Asset.

Main Success Scenario:

Step Details 400.10 The Asset generates a transaction with twotransaction inputs and two transaction outputs as shown in FIG. 4. Thetransaction inputs are: Asset issuance transaction (or last assetre-assignment), signed by the Asset with a SIGHASH_NONE flag set Incomedistribution amount, signed by the Asset with a SIGHASH_NONE flag setThis means that there is a signature missing from the first input andallows anyone to change the outputs of this transaction. However,because of the missing signature, this is effectively changed to a modelthat say that only the remaining signatory has the practical ability tochange the output of the transaction. In turn, this has allowed theAsset to create a payment transaction without knowing where to send thepayment, but certain that it will only get collected by the authorisedrecipient. The transaction outputs are: Transaction income distributioninput (less the mining fee) paid to the Asset's public key hash Assetissuance transaction, paid back to the same place as the input. 400.20Using the notification address for this redeem script (as determinedduring use case 200), the incomplete transaction is pushed to thecurrent Asset Holder. 400.30 Upon receipt, the Asset Holder changes thedestination of the second output to the Asset Holder's public key hash(e.g. paid to themselves) and then provides the second signature to theasset issuance transaction with a standard SIGHASH_ALL flag set. Notethat the re-direction of the income distribution output can be to anyaddress that the Asset Holder requires and is not restricted to beingtheir public key hash. 400.40 The Asset Holder then publishes thistransaction to the blockchain for it to be accepted and mined.

Transaction 400.10—Interim (Incomplete) transaction is shown in FIG. 11. Transaction 400.10—final (complete transaction) is shown in FIG. 12 .In FIG. 12 , the amendments are shown in bold for clarity.

Example Scenario: Asset Share Capital

The main type of scenario that is supported by this model is thetraditional share capital for an asset such as a company. The company(NewCo plc) will issue a fixed amount of shares (1,000) that can befreely traded, with income paid out on a periodic basis (annually). Asthe income distribution represents the profit of the company, there isno requirement to support the collection of costs from the asset holderbase (profit has already had the costs netted off from them).

Key Benefits of the Invention Include

The invention enables autonomous activity against a blockchain, allowingfor entities that are created where income/costs can be paid withouthaving to maintain (except for regulatory reasons) a separate off-chaindatabase of ownership.

The invention enables a notification address or identifier to beembedded within a transaction, and specifically within the script of atransaction.

Thus, the invention provides enhanced privacy, security andcommunication. It is particularly advantageous in applications relatingto the control and recordal of a transfer of assets and/or funds via ablockchain.

It should be noted that the above-mentioned embodiments illustraterather than limit the invention, and that those skilled in the art willbe capable of designing many alternative embodiments without departingfrom the scope of the invention as defined by the appended claims. Inthe claims, any reference signs placed in parentheses shall not beconstrued as limiting the claims. The word “comprising” and “comprises”,and the like, does not exclude the presence of elements or steps otherthan those listed in any claim or the specification as a whole. In thepresent specification, “comprises” means “includes or consists of” and“comprising” means “including or consisting of”. The singular referenceof an element does not exclude the plural reference of such elements andvice-versa. The invention may be implemented by means of hardwarecomprising several distinct elements, and by means of a suitablyprogrammed computer. In a device claim enumerating several means,several of these means may be embodied by one and the same item ofhardware. The mere fact that certain measures are recited in mutuallydifferent dependent claims does not indicate that a combination of thesemeasures cannot be used to advantage.

What is claimed is:
 1. A method comprising: submitting a transaction toa blockchain, wherein the transaction (Tx₁) comprises an unspent output(UTXO) that includes a redeem script that requires the provision of anotification address within the metadata of an unlocking script in orderto spend the output (UTXO).
 2. The method of claim 1, furthercomprising: sending an electronic notification to the notificationaddress that is provided as metadata within the unlocking script.
 3. Themethod according claim 2, wherein: the electronic notificationcomprises: an incomplete or complete blockchain transaction, and/orinformation relating to the location of, or means of access to, anincomplete blockchain transaction; and/or information relating to anincomplete or complete blockchain transaction.
 4. The method accordingto claim 1, wherein: the notification address is associated with anasset or resource represented on the blockchain, or a controller of anasset or resource represented on the blockchain.
 5. The method accordingto claim 1, and further comprising: traversing the blockchain toidentify the transaction (Tx₁) or a further transaction (Tx₂).
 6. Themethod according to claim 1, wherein: the unspent output (UTXO)transfers ownership or control of, or otherwise relates to, a tokenisedasset represented on, or referenced via, the blockchain.
 7. The methodaccording to claim 1, wherein the redeem script comprises: a valueindicating how many notification addresses must be supplied by theunlocking script.
 8. The method according to claim 1, wherein: thenotification address is a network address, a cryptographic key, auniform resource locator (URI), email address, or any other address oridentifier that can be represented in the metadata of a script and usedas a destination for an electronic communication.
 9. The methodaccording to claim 1, wherein the notification address is a destinationfor an off-blockchain electronic communication.
 10. The method accordingto claim 2, wherein: the electronic notification is sent by an automatedcomputing resource or agent.
 11. The method according to claim 2,further comprising: detecting a designated or predetermined event; andsending the electronic notification in response to detection of theevent.
 12. A computer-implemented system arranged and configured toperform the method of claim
 1. 13. A system according to claim 12,wherein the system comprises: a blockchain; and at least one autonomouscomputing agent arranged and configured to: traverse the blockchain;and/or generate and or send an electronic notification to thenotification address.